Hello,

+1 for proposing a path to remove the "template" keyword.
But I have the impression you are considering to add aliases. In the past, aliases caused a huge amount of trouble, because people have to discover them and when looking at scene must "know" by heart the aliases to understand the scenes. Having a single name is much better as it ease learning and discoverability.

@damienmarchal
It's also something that bothered me. That's also why this PR is only a draft.

I see only two options:

1. We use a unique keyword for the template parameters. It's the case right now, but the term template is not enough descriptive. I doubt we can find another keyword that would suit all the components, but I am open to discussion (dataType?)
2. We define another interface where the template keyword would be here just for compatibility. It could be the case in this PR. In that case, the term alias would not be appropriate. We could trigger a warning if the attribute template is used.

Actually, more generally, this PR defines the template parameters as an associative container key-value. And you are right, the user must know the key. But it is also the case for the Data. We found "solutions" for that: documentation (including the examples) and auto-completion.

Third option : We propose a "DataTypeParameters" component, holding all of such parameter for one node, fixing the parameters for all component in this node. Then because it is a component, the user will know where to look for.

I see only two options:
1. We use a unique keyword for the template parameters. It's the case right now, but the term template is not enough descriptive. I doubt we can find another keyword that would suit all the components, but I am open to discussion (dataType?)

2. We define another interface where the `template` keyword would be here just for compatibility. It could be the case in this PR. In that case, the term `alias` would not be appropriate. We could trigger a warning if the attribute `template` is used.

Actually, more generally, this PR defines the template parameters as an associative container key-value. And you are right, the user must know the key. But it is also the case for the Data. We found "solutions" for that: documentation (including the examples) and auto-completion.

To me "template" is just a bad name (a c++ concept) with very limit meaning for scenes makers. dataType or simply "type" is probably better. I'm unsure of the use of per component "type" because I will hide the fact this is a special purpose "keyword" and not a data.

About the implementation you are proposing, your are refering to the use of a "container key-value" then saying "the user must know the key". To me if you are using container then there could be multiple keys not a single one (this is what I understand from the use of the singular form for "key"). So if there is multiple "key", then theses are aliases I would not recommend to introduce. "template" should be a corner case just there to emit a warning to inform users to stop using this name and suggesting the new name.